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ORIGINS  OF  THE  PASCAL  LANGUAGE 


Pascal  is  an  increasingly  popular  program¬ 
ming  language  that  initially  interested 
academics.  Now  it  is  mentioned  in  Toronto 
newspapers!  In  North  America,  Pascal  is 
rapidly  replacing  PL/I  as  an  undergraduate 
teaching  tool  in  computer  science  depart¬ 
ments.  It  is  available  on  hardware  ranging 
from  large  mainframe  computers  (IBM, 
DEC,  CDC,  etc.)  to  home  computers  (e.g., 
TERAK,  APPLE). 

Pascal  was  developed  in  Europe  by  Profes¬ 
sor  Niklaus  Wirth  who  named  the  language 
after  the  17th  century  French  philosopher 
and  mathematician  Blaise  Pascal.  Professor 
Wirth’s  choice  of  Pascal  was  apt,  as  the  fol¬ 
lowing  brief  synopsis  of  Pascal’s  life  shows. 

Pascal  -  the  person 

Blaise  Pascal  was  born  in  France  in  1623. 
At  a  very  young  age,  he  showed  a  genius 
for  mathematics  and,  without  being  taught, 
discovered  a  great  deal  about  geometry.  At 
the  age  of  sixteen  he  wrote  a  book  on 
mathematics  and  by  the  age  of  twenty-six 
he  ranked  among  the  great  scholars  of  his 
time.  He  became  deeply  interested  in  reli¬ 
gious  thought.  His  famous  series  of  letters 
against  the  Jesuits,  called  the  Lettres  Provin¬ 
ciates,  was  written  in  a  style  that  was  so 
clear,  so  full  of  force  and  wit  and  so  com¬ 
pact  that  the  best  French  prose  has  been 
founded  on  the  same  principles  ever  since. 
He  died  in  Paris  in  1662  when  only  thirty- 
eight  years  old. 

ALGOL  -  the  predecessor 

In  1960,  a  European  Committee  published 
the  ALGOL-60  report  in  which  it  specified 
the  syntax  and  semantics  of  an  algorithmic 
language  using  a  meta-language  called  BNF 
(Backus-Naur  Form).  While  the  ALGOL 
language  became  popular  in  Europe,  it 
proved  less  popular  in  the  United  States 
and  Canada  where  FORTRAN  was  dom¬ 
inant. 


ALGOL-W  -  an  improvement 

In  the  early  1960s,  Swiss-born  Wirth  pub¬ 
lished  Euler:  A  Generalization  of  ALGOL. 
While  at  Stanford  he  developed  a  dialect  of 
ALGOL-60  called  ALGOL-W.  The  princi¬ 
ple  feature  of  ALGOL-W  was  the  concept 
of  programmer-defined  datatypes  called 
records.  While  ALGOL-60  provided  users 
with  multi-dimensional  arrays  for  the 
storage  of  data,  users  could  group  together 
items  only  if  they  had  the  same  type.  With 
ALGOL-W  this  restriction  was  removed 
and  users  could  begin  to  structure  both 
their  programs  and  their  data. 

The  more  structures  Professor  Wirth  at¬ 
tempted  to  add  to  ALGOL,  the  more  dissa¬ 
tisfied  he  was  with  it.  It  became  clear  that 
while  ALGOL  addressed  the  problem  of 
structured  programs,  it  could  not  be  ex¬ 
tended  enough  to  allow  truly  structured 
data. 

Pascal  -  the  teaching  tool 

Upon  his  return  to  Switzerland,  Professor 
Wirth  began  work  on  a  new  language  which 
would  easily  support  data  structures.  He 
basically  had  two  goals: 

•  to  create  a  language  that  handled  flow 
and  data  in  a  structured  manner  and  that 
would  be  suitable  for  teaching  the  art  of 
computer  programming; 

®  to  effect  an  implementation  that  would 
be  reliable  and  efficient. 


The  first  implementation  of  Pascal  was 
made  for  a  CDC  machine  in  1970.  In  that 
same  year  the  Pascal  Report  was  published. 
This  report  was  widely  circulated  within  the 
academic  community  where  it  appealed  to 
compiler  writers  and  people  interested  in 
programming  languages.  By  the  mid-1970s, 
Pascal  had  been  implemented  on  a  variety 
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PASCAL  LANGUAGE  continued 

of  machines,  from  the  large  mainframes  of 
various  manufacturers  to  minicomputers. 
Today  Pascal  is  even  offered  on  microcom¬ 
puters.  It  is  fast  becoming  the  de  facto 
standard  programming  language. 

Pascal  Standards 

A  separate  Pascal  committee  has  been  esta¬ 
blished  in  cooperation  with  the  British  Stan¬ 
dards  Institute  (BSD,  the  International 
Standards  Organization  (ISO)  and  the 
American  National  Standards  Institute 
(ANSI).  This  committee  has  proposed  a 
draft  standard  for  Pascal  which  attempts  to 
clarify  ambiguities  in  the  original  Pascal  Re¬ 
port. 

Another  organization  has  even  assembled  a 
test  of  programs  called  the  Pascal  Validation 


Suite.  This  can  be  used  to  ‘test’  various 
implementations  of  Pascal  to  see  if  they  fol¬ 
low  the  standards  outlined  in  the  draft  pro¬ 
posal. 

Since  Pascal  is  available  on  such  a  wide 
variety  of  machines  and  since  it  also  sup¬ 
ports  both  structured  programming  and 
structured  data,  it  is  ideal  as  a  language  for 
writing  transportable  programs  (which  can 
be  easily  transported  from  one  machine  to 
another). 

Another  article  follows  in  this  issue, 
describing  the  versions  of  Pascal  available 
at  UTCS.  Next  month,  in  The  Pascal 
Language  Defined,  we  shall  present  a  brief, 
technical  introduction  to  Pascal. 


Mark  Tapia 


PASCAL  IMPLEMENTATIONS  AT  UTCS 


Pascal  implementations  are  available  on  a 
variety  of  systems  at  UTCS,  from  micro- 
and  mini-computers  to  large  mainframes. 
The  implementations  of  Pascal  fall  into  two 
broad  categories: 

•  the  total  systems  approach  -  In  this  case, 
Pascal  is  an  integral  part  of  the  operating 
system.  The  editor,  linker  and  loader  all 
know  about  the  Pascal  language  and  li¬ 
brary.  Everything  is  designed  to  allow 
the  user  to  think  of  the  computer  as  a 
Pascal  machine. 

•  the  language  processor  approach  -  This  is 
the  standard  implementation  for  most 
language  processors.  Standard  editors 
are  used  to  prepare  programs.  These 
programs  are  then  compiled  and  execut¬ 
ed. 


Communications  and  Small  Systems 
(CSS) 

The  following  Pascal  implementations  are 
available  at  CSS. 


The  UCSD  System 

The  University  of  California  at  San  Diego 
(UCSD)  has  developed  a  total  systems  ver¬ 
sion  ol  Pascal.  The  UCSD  system  is 
currently  marketed  by  Softech  Microsys¬ 
tems  of  San  Diego,  California,  for  PDP- 
1 1  /LSI- 1 1  systems. 

The  UCSD  system  is  a  complete  operating 
system  which  has  been  implemented  on  a 
number  ot  micro-  and  mini-computers.  Al¬ 
most  all  of  the  system  is  written  in  Pascal, 
for  the  purpose  of  portability.  It  is  an  inter¬ 
pretive  system.  The  UCSD  system  consists 
of  several  components: 

®  The  filer  allows  users  to  delete,  copy, 
rename  files  and  produce  a  directory  list¬ 
ing. 

•  The  editor  formatter  helps  the  program¬ 
mer  to  enter  and  modify  Pascal  programs 
and  text. 

•  The  compiler  compiles  the  Pascal  pro¬ 
gram  producing  P-code  which  can  then 
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PASCAE  IMPLEMENTATIONS  continued 

be  interpreted.  (A  FORTRAN  compiler 
is  also  available.) 

®  The  linker  links  previously-compiled  Pas¬ 
cal  programs  producing  a  tile  which  can 
be  executed. 

®  The  interpreter  executes  Pascal  programs. 

®  The  assembler  allows  users  to  write  spe¬ 
cialized  routines. 

The  UCSD  system  is  available  on  the  fol¬ 
lowing  systems  at  CSS: 

®  The  APPLE  II  PLUS  (micro)  system 
offers  an  implementation  of  Pascal  which 
incorporates  turtle-graphics.  (The  turtle 
is  the  hand-held  device  connected  to  a 
digitizing  tablet.)  The  turtle-graphics 
package  allows  simple  programming  of 
pictures  in  colour  using  a  ‘virtual’  turtle. 
APPLE  Pascal  also  allows  musical  pro¬ 
grams  to  be  written  to  utilize  the  built-in 
speaker. 

®  The  Western-Digital  Pascal  MicroEngine 
(micro)  is  different  from  other  systems 
in  that  it  executes  P-code  directly,  as  op¬ 
posed  to  interpreting  it.  This  allows  it  to 
run  Pascal  programs  5  to  10  times  faster 
than  other  micro-computers. 

®  The  PDP-11  (mini)  Lab  systems  (GT44 
and  GT40)  also  offer  UCSD  Pascal. 


OMSI  Pascal 

A  compiler  version  of  Pascal,  called  OMSI 
Pascal,  is  available  at  CSS.  This  version  is 
distributed  by  Oregon  Minicomputer 
Software  Incorporated.  OMSI  Pascal  runs 
under  the  RT-11  operating  system  and  is 
available  on  the  GT44  and  GT40  Lab  sys¬ 
tems. 

Users  who  wish  to  use  these  CSS  systems 
should  consult  their  CSR  or  the  CSS  lab 
co-ordinater,  Phil  Selby,  at  978-4600. 

DEC- 10 

The  following  Pascal  implementation  is 
available  on  the  DEC- 10. 


Pascal  is  a  compile  class  language  on  the 
DEC- 10  computer.  If  a  Pascal  program  is 
in  a  file  with  a  PAS  extension  then  the  pro¬ 
gram  can  be  executed  using  the  standard 
EX  (EXECUTE)  command.  Documenta¬ 
tion  on  the  Rutgers  implementation  of  Pas¬ 
cal  for  the  DEC-10  is  available  in  the  fol¬ 
lowing  files: 

HLP:Pascal.HLP  -  Pascal  help  file 
L)OC:Pascal.M AN  -  Pascal  manual 
DOC:Pascal.DOC  -  additional  documentation 


IBM  3033 

The  following  Pascal  implementations  are 
available  on  the  IBM  3033. 

High  Speed  Job  Stream 

University  of  Waterloo  Pascal 

The  University  of  Waterloo  version  of  Pas¬ 
cal  is  available  on  the  High  Speed  Job 
Stream.  Like  other  language  processors 
available  on  HSJS,  Waterloo  Pascal  is  ideal¬ 
ly  suited  for  student  use.  It  compiles  pro¬ 
grams  quickly.  It  generates  good  compile¬ 
time  and  run-time  error  messages  and 
checks  for  a  wide  variety  of  errors.  It  exe¬ 
cutes  programs  fairly  quickly.  It  terminates 
gracefully. 

While  there  is  currently  no  standard  version 
of  Pascal,  a  draft  standard  has  been 
developed  by  the  British  Standards  Institute 
and  the  International  Standards  Organiza¬ 
tion  and  will  probably  become  the  industry 
standard.  The  Waterloo  implementation 
conforms  to  this  proposed  standard. 

This  implementation  also  contains  addition¬ 
al  functions  for  converting  real  numbers  to 
strings  (RTOS)  and  strings  to  real  (STOR) 
as  well  as  an  arc  tangent  function  with  two 
arguments. 

UTCS  has  also  added  other  features  which 
make  our  implementation  conform  to  those 
of  PL/C,  SP/k  and  WATF1V.  These 
features  are  summarized  below. 
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PASCAL  IMPLEMENTATIONS  continued 

•  standard  control  cards  -  Waterloo  Pascal 
supports  the  standard  SJOB  and  $DATA 
cards  which  respectively  signal  the  start 
and  end  of  a  job. 

®  The  library  inclusion  facility  is  available 
for  incorporating  source  and/or  data 
cards  into  the  input  stream.  (A  $IN- 
CLUDE  card  is  used  to  specify  the  file  to 
be  used.) 

®  scratch  files  -  Four  scratch  files  are  sup¬ 
ported.  The  characteristics  of  these  files 
are  fixed  and  cannot  be  changed  by  the 
user.  Card  image,  line  printer  hies  and 
files  containing  a  large  record  size  are 
supported. 

®  read  only  files  -  Users  can  effectively 
open  a  member  of  the  HSJS  library  for 
input  and  tie  it  to  a  filename. 


Additional  details  on  Waterloo  Pascal  are 
contained  in  USERBOOK  Module 
3.6HSWPASCAL.  Users  who  subscribe  to 
USERBOOK  may  request  copies  of  this 
module.  All  other  users  may  obtain  the 
manual  from  the  Information  Office  or  by 
contacting  their  CSR. 

The  Waterloo  compiler  is  also  available 
through  batch  by  using  the  following  deck 
setup: 


//  EXEC  HSJS 
//GO.SYS1N  DD  * 
SJOBP  ID  = ‘TEST’ 
Pascal  program 
SDATA 
data 


General  Purpose  Job  Stream 

There  are  currently  two  UTCS  -  supported 
versions  of  Pascal  available  on  GPJS:  the 
University  of  Waterloo  Pascal  compiler  and 
the  Australian  Atomic  Energy  Commission 
Pascal  Compiler  (AAEC  Pascal). 


Waterloo 

The  Waterloo  compiler  is  intended  for  stu¬ 
dent  use  or  for  debugging  Pascal  programs. 
Since  the  compiler  trades  off  faster  compila¬ 
tion  time  for  slower  execution  time,  the 
Waterloo  version  should  not  be  used  for 
production  runs.  The  compiler  is  available 
in  two  different  versions.  To  execute  the 
HSJS  version  through  GPJS,  the  HSJS  pro¬ 
cedure  should  be  used.  The  following  deck 
setup  will  run  a  Pascal  program  on  GPJS: 

//  EXEC  HSJS  [,SCRATCH  =  YES] 
//GO.SYSIN  DD  * 

SJOBP 

Pascal  program 
SDATA 
data 


Code  Scratch  =yes  if  you  wish  to  use 
scratch  files. 

The  unmodified  version  of  the  Pascal  com¬ 
piler  is  also  available.  The  deck  setup  is: 

//  EXEC  WPASCAL 
//GO.SYSIN  DD  * 

Pascal  program 
SENTRY 
data 


AAEC  Pascal 

The  AAEC  compiler  is  intended  for  Pascal 
jobs  which  require  large  execution  times  or 
which  have  been  fully  debugged  and  are  in 
production.  To  compare  this  compiler  with 
the  Waterloo  compiler,  we  ran  a  large  pro¬ 
gram  under  both,  as  two  separate  jobs.  We 
then  compared  the  total  CPU  time.  This 
program,  which  executed  3.5  million  state¬ 
ments,  took  229  seconds  under  the  Water¬ 
loo  version  and  8.2  seconds  under  the 
AAEC  version.  Thus,  the  AAEC  compiler 
runs  up  to  27  times  faster  than  the  Water¬ 
loo  compiler. 

The  AAEC  version  allows  users  to  link  oth¬ 
er  Pascal  programs  and  to  call  FORTRAN 
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PASCAL  IMPLEMENTATIONS  continued 

routines  from  within  a  Pascal  program,  as 
well  as  to  use  previously  compiled  Pascal 
programs.  The  IBM  can  access  the  UTCS 
FORTRAN  subroutine  libraries  (1MSL, 
EISPAK,  etc.).  These  libraries  are  speci¬ 
fied  through  the  IX,  LIBRARY  and  1X2, 
and  L1B2  parameters  in  a  manner  similar  to 
that  used  in  the  standard  FORTLE,  FORT- 
GO  and  FORTLEGO,  and  PLILE, 
PLILEGO,  PLIGO  procedures. 

The  following  deck  setup  should  be  used  to 
access  the  AAEC  compiler: 


//  EXEC  PASLEGO 
//PAS.SYSIN  DD  * 

Pascal  program 
//LE.SYSIN  DD  * 
linkage  editer  control  cards 
//GO.SYSIN  DD  * 
data  cards  for  INPUT  file 


Documentation  is  available  by  executing 
the  following  procedure: 

//  EXEC  I P  ASM  AN,  VERSION  =  AAEC, 

//  FOR  MS -forms 


Users  should  allow  15,000  lines  for  execu¬ 
tion  output.  The  manual  will  be  printed  on 
forms  2018  (thesis  paper)  if  the  FORMS 
parameter  is  omitted. 


Pascal/VS 

In  August,  IBM  announced  its  own  version 
of  Pascal  -  Pascal/VS.  We  are  planning  to 
evaluate  this  product  and  may  install  it  on 
GPJS. 

Pascal/VS  supports  the  draft  ISO  standard 
and  contains  the  following  additional  exten¬ 
sions: 

®  an  include  facility  for  incorporating  text 
from  source  libraries 

®  linkage  to  FORTRAN,  COBOL  and  As¬ 
sembler  language  subprograms.  Assem¬ 
bler  macros  are  available  for  communi¬ 
cating  with  Pascal  programs. 

®  dynamic  character  stages 

®  assertion  statements  to  specify  errors 
(similar  to  PL/I) 

®  extended  input/output  support  including 
interactive  partitioned  data  set  and 

®  limited  exit  from  loops  (leave) 

®  predefined  procedures  for  obtaining  sys¬ 
tem  information 

®  additional  functions  including  bit  mani¬ 
pulating  (shift  left,  shift  right,  logical  and 
and  logical  or) 

®  static  declarations  to  save  values  between 
invocations. 


Mark  Tapia 


STELLAR  STORY:  PORTRAIT  OF  A  USER 


“I  was  born  under  a  lucky  star,”  said 
American  writer  Henry  Miller  (among  oth¬ 
er  quotations,  decidedly  unprintable  in 
COMPUTERNEWS).  This  sentiment  is  not 
exclusively  Mr.  Miller’s  -  I’ve  said  it,  and 
meant  it.  You  have  too,  at  least  once, 
right? 

Everyone  is  ‘star-struck’  at  some  time  or 


other.  ‘Starry-eyed’  (infatuated);  ‘‘I  saw 
stars,”  (I  was  knocked  unconscious);  Lost 
in  the  Stars  (remember  Frank  Sinatra  ...  the 
50s?);  and  The  Jefferson  Starship 
(remember  rock  ...  the  70s?)  are  all  varia¬ 
tions  on  ‘stellar.’ 

Astrologers  are  students  of  the  celestial  ... 
Taurus,  Gemini,  Leo,  ... 
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Science  studies  stars.  Consider  derivations 
of  the  Greek  root  word  astron  or  star  ... 

•  astronomy:  science  of  the  heavenly  bo¬ 
dies  (planets,  comets,  black  holes,  galax¬ 
ies) 

•  astronaut:  space  traveller 

•  astrolabe:  instrument  for  measuring  alti¬ 
tudes  of  stars,  etc. 

•  astrobotany(l):  study  of  plants  on  celes¬ 
tial  bodies 

•  astronomical:  (distances)  as  enormous  as 
those  familiar  to  astronomers 

However,  if  you  think  astronomer/U  of  T 
Professor  Morris  Clement  has  a  romantic  or 
random  attraction  to  stars,  please  be  aware 
that,  in  his  work,  he  is  more  intimate  with 
a  WYLBUR  terminal,  the  UTCS  computer 
and  differential  equations  than  with  twin¬ 
kles  in  a  black,  velvet  night  at  the  other 
end  of  a  telescope. 

Though  1  shall  describe  a  scientific  concern 
with  celestial  bodies,  don’t  be  intimidated. 
Note  these  evocative  lines  from  the  table  of 
contents  of  a  university  astronomy  text¬ 
book: 

•  Red  Giants 

•  Observing  White  Dwarfs 

•  Detecting  a  Black  Hole 

•  Farther  Clusters  of  Galaxies 
®  The  Big  Bang  Theory 

The  poetical  quality  inherent  in  things  as¬ 
tronomical  should  sustain  your  interest, 
dear  reader,  in  the  complex  work  of  Morris 
Clement,  featured  briefly  in  this  month’s 
user  profile. 


I  prefaced  the  interview  with  a  question  ... 

if  you,  an  astronomer,  were  on  a  deserted  is¬ 
land,  which  would  you  choose  to  have  -  a  tele¬ 
scope  or  a  computer  ? 

He  laughed.  The  answer  follows. 


An  astronomer  might  be  a  theoretician  or  an 
observer.  The  former  could  construct 
mathematical  models  of  stars,  measuring 
stellar  interiors  or  determining  chemical 
compositions  of  stars.  The  latter  would  col¬ 
lect  specific  data  by  looking  in  the  heavens 
at  particular  celestial  bodies.  Theoreticians 
use  computers;  observers  use  telescopes.  A 
theoretician  like  Professor  Clement  is  basi¬ 
cally  concerned  with  mathematics  and 
doesn’t  have  a  great  deal  of  contact  with 
observational  data  (although  it’s  always  in 
the  back  of  his  mind). 

This  differentiation  is  not  rigid.  Certain 
theoreticians  do  work  with  data  supplied  by 
observers,  interpreting  it  to  build  a  particu¬ 
lar  stellar  model  explaining  that  set  of  data. 

If  you’re  non-astronomical,  please  consider 
before  reading  further  that: 

•  Since  much  of  the  mass  of  the  universe 
is  in  the  form  of  stars,  stellar  study  is  ob¬ 
viously  important,  of  scientific  interest. 

•  We’re  a  planet  but  the  sun  is  a  star.  The 
mass  of  Jupiter,  the  largest  planet  in  the 
solar  system,  is  only  1/1000  the  mass  of 
the  sun! 

•  Astronomers  don’t  talk  about  weight. 
They  talk  about  something  more  abso¬ 
lute  -  mass  of  objects.  Weight  is  a  rather 
self-centred  measure  -  it  refers  only  to  a 
measure  of  gravitational  attraction  to 
Earth.  For  example,  if  you  were  off  in 
space,  you  wouldn’t  have  weight  but  you 
would  still  have  mass.  If  you  went  to 
the  moon,  your  mass  would  be  the  same 
but  your  weight  would  be  1/6  of  what  it 
is  here. 

•  Professor  Clement  doesn’t  use  familiar 
measures  or  sizes;  he  uses  a  unit  of 
measure  called  solar  mass  (mass  of  the 
sun).  He  commonly  deals  with  15  solar 
mass  stars.  The  lowest  mass  for  a  star  is 
about  1/10  solar  mass. 

•  Similarly,  radii  and  luminosities  are  usu¬ 
ally  measured  relative  to  the  sun’s. 
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•  Professor  Clement  deals  with  long  time 
spans  -  billions  of  years.  He  assured  me 
that  it  won't  be  until  5  billion  years  have 
passed  that  the  sun  will  run  out  of  hy¬ 
drogen  to  burn  for  fuel  at  which  time  it’s 
central  regions  will  suddenly  collapse. 
The  outer  parts  will  expand  and  the  sun 
will  become  a  giant  star  whose  radius  will 
increase  by  a  factor  of  about  100  to  reach 
out  past  the  orbit  of  Mercury  and  con¬ 
sume  it!  “Nobody  has  to  worry,”  reas¬ 
sured  Professor  Clement. 

•  Professor  Clement  deals  with  rotating 
stars.  The  physics  of  rotating  stars  is  not 
as  well  understood  as  the  physics  of 
spherical  stars.  He  builds  models  for  a 
range  of  masses,  to  see  the  varying  ef¬ 
fects  of  rotation  on  these  different 
masses.  (i.e.,  how  rotation  changes 
luminosity  of  the  star  or  the  distribution 
of  density  inside  the  star.) 


“Most  of  the  research  on  stellar  structure 
has  been  done  in  the  last  twenty  years,  with 
the  advent  of  the  computer.  Almost  all 
work  is  concentrated  on  spherical  stars,  for 
obvious  reasons.  Numerically,  it’s  a  much 
simpler  form  -  it’s  one  space  dimension. 

With  a  revolving  star,  there’s  a  timing  di¬ 
mension  too.  It’s  basically  a  two- 
dimensional  problem.  However,  rotating 
stars  are  not  spherical  -  they’re  flattened  or 
oblique.  And  so  if  it’s  actually  symmetri¬ 
cal,  there  are  two  space  dimensions.  Nu¬ 
merically,  this  order  of  magnitude  is  more 
difficult. 

Scientists,  in  fact,  have  not  yet  evolved  ro¬ 
tating  stars  in  time  because  it  becomes  a 
very  complex  three-dimensional  problem. 

As  an  example  of  my  own  work,  1  might 
take  a  particular  mass,  a  15  solar  mass.  I’ll 
start  with  a  spherical  star  -  no  rotation  -  and 
build  a  model. 

Next,  1  apply  a  bit  of  rotation  and  build  a 
model  for  that  to  see  how  it’s  physical  vari¬ 
ables  have  changed,  variables  such  as  densi¬ 
ty,  temperature,  pressure,  chemical  compo¬ 


sition  and  perhaps  flux  of  radiation.  I 
would  then  continue  to  build  other  models, 
rotating  even  more  rapidly.  And  1  could 
also  vary  how  rotation  is  distributed  in  the 
star! 

But  ...  one  has  to  evaluate  those  variables 
at  every  point  in  the  interior  of  the  star  - 
density  at  the  surface,  at  one  mile  down,  at 
two  miles  down,  at  one  million  miles  down. 
One  needs  to  get  the  run  of  density 
throughout  the  interior  of  the  star  and  the 
run  of  all  the  other  physical  variables,  men¬ 
tioned  above.  To  evaluate  the  variables  at 
many  different  points  and  to  calculate  them 
requires  solving  a  differential  equation. 

This  is  done  using  the  computer.  There 
were  a  few,  simple  models  computed  before 
World  War  II,  with  desk  calculators  (cer¬ 
tainly  not  models  of  stars  that  evolved  in 
time  however;  that  would  have  been  impos¬ 
sible).  An  astronomer  at  that  time  would 
have  constructed  a  stellar  model  at  a  given 
moment.  He  could  find,  roughly  and  over 
a  period  of  several  months,  the  distribution 
of  density,  temperature,  pressure  and  so 
on. 

To  do  a  stellar  model  evolving  in  time,  one 
must  construct  a  sequence  of  perhaps  a 
thousand  models,  separated  by  just  a  few 
years  if  the  star  evolved  rapidly  or  by  mil¬ 
lions  of  years  if  it  was  evolving  very  slowly. 
If  done  by  hand,  these  calculations  would 
take  hundreds  of  years! 

All  these  calculations  have  to  be  done  by 
iteration;  there’s  no  one  calculation  to  get  a 
final  answer.  They  require  standard 
methods  of  numerical  analysis.  One  solves 
both  ordinary  and  partial  differential  equa¬ 
tions.  Although  when  you're  on  new 
ground,  as  I  am  here  with  rotating  stars,  I 
really  have  to  develop  my  own  numerical 
techniques. 

Further,  I  have  been  doing  stability  analyses 
of  these  models.  One  can  learn  something 
about  the  structure  of  stars  by  examining 
their  stability.  1  am  interested  in  knowing 
how  a  star  reacts  if  it  is  purturbed  in  some 
way.  Will  it  suddenly  explode?  Will  it 
change  into  another  form?  (In  principal. 
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planetary  systems  form  as  a  result  of  the  ra¬ 
pid  spinning  of  matter  that  eventually  starts 
Hying  off.)  We're  interested  in  how  rotation 
will  affect  oscillation  and  the  periods  and 
ways  in  which  a  star  oscillates.  That  also  is 
a  very  difficult  numerical  problem.  I’ve 
been  burning  up  a  lot  of  computer  time  in 
the  last  couple  of  years,  examining  the  sta¬ 
bility  of  these  rotating  models.” 


As  you  may  have  gathered  by  now,  what 
appears  in  the  sky  to  an  observer  as  a  hot, 
very  bright,  white  star  is,  to  Professor 
Morris  Clement,  probably  a  15  solar  mass 
star  on  paper,  the  subject  of  calculations 
done  in  the  normal  batch  run  at  UTCS,  the 
program  personally  edited  and  submitted 
using  WYLBUR. 

Yes,  dear  reader,  he  chose  the  computer  - 
our  computer. 


Pat  Longstajf  Smith 


YEAR-END  ACCOUNTING 


University  of  Toronto  budgets  are  esta¬ 
blished  on  an  annual  basis.  Similarly, 
users'  accounts  with  UTCS  are  funded  on  a 
corresponding  year-to-year  basis.  The 
logistics  of  posting  final  billings  from  UTCS 
to  the  Comptroller’s  Office  have  created 
confusion  and  difficulty  in  past  years.  Both 
the  Comptroller's  Office  and  UTCS  are  at¬ 
tempting  to  eliminate  or  minimize  any  disr¬ 
uption  of  computing  service  due  to  year- 
end.  The  following  explains  the  procedures 
and  options  available  to  you  for  this  year- 
end.  Please  note  that  accounts  funded  by 
grants  must  be  treated  differently  from 
University-funded  accounts.  For  this  rea¬ 
son  the  following  is  split  into  two  major 
divisions.  Research  Accounts  and  Adminis¬ 
trative  &  Educational  Accounts  (UNI¬ 
FACTS  90  and  98  accounts). 

Research  Accounts 

Most  sponsored  research  accounts  expire 
on  March  31.  The  Comptroller’s  Office 
must  receive  all  charges  to  be  applied 
against  the  Purchase  Order  for  the  present 
research  year  by  March  30.  Therefore, 
March  29  will  be  the  last  day  that  computer 
access  may  be  obtained  and  charged  against 
accounts  expiring  March  31. 

First,  account  administrators  whose  grants 
may  be  extended  into  the  next  year  or 
those  who  expect  new  funds  should  notify 
the  UTCS  Accounting  Office.  The  notifica¬ 


tion  may  be  either  a  copy  of  a  Purchase  Re¬ 
quisition  or  a  Fetter  of  Intent  from  the 
proper  budgetary  authority  stating  the 
amount  of  funding  expected.  Upon  receipt 
of  written  notification  the  account  will  be 
permitted  access  even  though  it  may  be 
temporarily  unfunded.  To  ensure  uninter¬ 
rupted  service,  the  notification  must  be  re¬ 
ceived  by  March  26.  Note  that  usage  after 
March  29  will  be  charged  against  the  new 
source. 

Second,  research  users  who  are  subsidized 
by  their  departments  may  continue  to  com¬ 
pute  wholly  funded  by  the  subsidy  until  it  is 
spent  or  until  the  subsidy  account  expires 
on  April  30.  Users  may  choose  to  discuss 
additional  subsidy  funds  with  their  Depart¬ 
mental  Representatives. 

Third,  account  administrators  of  accounts 
which  will  not  be  receiving  continuing 
funds  should  close  the  accounts  with  a 
Change  of  Account  Status  form  (see  exam¬ 
ple  insert). 

If  the  account  administrator  does  not  select 
any  of  the  above  options,  there  will  be  a 
one  month  grace  period  for  any  auxiliary 
services  such  as  data  storage.  At  the  end  of 
the  grace  period,  April  30,  the  data  storage 
will  be  subject  to  deletion. 
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Administrative  and  Educational  Accounts 
(Unifacts  90  and  98  Accounts) 

Both  the  Comptroller’s  Office  and  UTCS 
are  pleased  to  report  that  the  1980-81  year- 
end  should  be  far  simpler  than  preceding 
years.  Administrative  &  Educational  ac¬ 
counts  will  be  allowed  to  run  through  April 
30.  All  charges  for  computer  usage 
through  that  date  will  be  applied  against  the 
1980-81  account. 

Account  administrators  are  urged  to  fund 
their  continuing  accounts  for  1981-82  as 
soon  as  possible.  This  may  be  done  by  pro¬ 
viding  the  UTCS  Accounting  Office  with  a 
copy  of  a  Purchase  Requisition  for  the  next 
fiscal  year. 

Or,  if  the  Purchase  Order  is  not  prepared  in 
time,  the  administrator  will  be  extended 
credit  if  his  budgetary  authority  provides 


UTCS  with  a  Letter  of  Intent  specifying  the 
amount  of  funding  expected.  Administra¬ 
tors  should  notify  the  Accounting  Office  by 
April  26  to  ensure  uninterrupted  service. 

Account  Administrators  should  be  aware 
that  accounts  which  are  without  continuing 
funding  will  become  inactive  after  April  30 
and  are  subject  to  being  closed. 

There  will  be  a  one  month  grace  period  for 
any  auxiliary  services  such  as  data  storage. 
At  the  end  of  the  one  month  period,  the 
data  storage  is  subject  to  deletion.  UTCS 
requests  that  administrators  who  no  longer 
require  access  or  data  storage  expedite  the 
process  by  closing  the  account  with  a 
Change  of  Account  Status  form. 

Don  Gibson 


STRATEGIC  ISSUES  IN  PROVIDING  COMPUTING  AT  U  OF  T 


In  last  month’s  article.  Background  for 
VIVA,  we  discussed  issues  and  trends  ap¬ 
parent  in  the  data  processing  industry.  In 
this  article,  we  will  look  at  computing  at  the 
University  of  Toronto.  Our  VIVA  series 
continues  next  month. 

In  considering  the  evolution  of  computing 
at  U  of  T  from  its  current  form  to  a  distri¬ 
buted  system,  the  following  components  of 
the  existing  services  have  been  considered 
for  possible  decentralization: 

•  Computing  Hardware 

•  Operations 

•  Systems  Software  Development 

•  Communications  Systems 

•  User  Services  and  Publications 

•  Systems  Management 

Computing  Hardware 

Both  centralized  and  decentralized  hardware 
should  be  employed.  The  decentralized  fa¬ 
cilities  can  take  the  form  of  individual 
workstations  or  of  small  interactive  time¬ 


sharing  machines  supporting  communities 
of  users  with  similar  interests,  i.e.,  depart¬ 
ments,  laboratories  or  instructional  centres. 
The  type  of  work  done  in  each  of  these 
domains  should  be  that  which  is  best  suited 
to  the  tools  available,  i.e.,  both  the  central 
site  services  and  distributed  machines 
should  be  streamlined  and  optimized  for 
the  tasks  they  do  best.  This  combination 
affords  the  highest  quality  services  at  the 
least  cost,  since  the  systems  can  be  tailored 
for  effectiveness  and  efficiency.  Due  to  the 
problems  of  maintenance,  it  is  important  to 
develop  ways  of  using  the  central  site  facili¬ 
ties  to  monitor  the  other  computing  facili¬ 
ties  so  that  repairs  may  be  done  in  a  timely 
and  efficient  fashion. 

Operations 

The  central  site  facility  would  continue  to 
require  an  operations  staff.  An  important 
consideration  for  the  distributed  sites  is  that 
they  should  require  a  minimal  operations 
staff  of  their  own.  Through  the  use  of  the 
centralized  facility  for  data  and  program  dis¬ 
tribution  and  maintenance,  the  user  is  pro- 
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vided  with  the  portion  of  the  centralized 
operation  that  he  needs.  But  because  of  the 
inherent  simplicity  and  private  nature  of  his 
local  facilities,  he  may  work  with  minimal 
(if  any)  additional  operations  staff  at  his 
site.  An  additional  benefit  is  derived  by  the 
central  site  operations  staff  who  are  not  bur¬ 
dened  with  complex  subsystems  which  sup¬ 
port  user  activities  done  directly  on  the  dis¬ 
tributed  computers. 

Systems  Software  Development 

This  function  must  be  provided  as  a  central 
service,  but  could  be  augmented  by  exten¬ 
sions  provided  by  the  user  community. 
The  large  investment  in  software  develop¬ 
ment  demands  that  it  be  protected  by  the 
enforcement  of  standards  pertaining  to  its 
quality,  efficiency,  adaptability  and  ability  to 
interface  to  existing  services  (both  central¬ 
ized  and  decentralized).  The  system  level 
software  used  in  a  distributed  system  must 
be  constructed  and  maintained  by  profes¬ 
sionals  who  have  been  trained  in  the  discip¬ 
line  of  software  engineering.  The  intent  of 
this  requirement  is  not  to  limit  or  constrain 
the  use  of  the  decentralized  units,  but  to 
provide  basic  services  to  ease  the  burden 
on  the  user  and  to  provide  these  services  at 
the  high  level  of  quality  that  the  user  com¬ 
munity  expects.  There  is  an  underlying 
principle  in  this  issue:  a  minimum  set  of 
skills  is  required  to  design,  develop  and 
maintain  computing  systems,  no  matter 
how  the  hardware  may  be  dispersed  and  in¬ 
terconnected.  The  problem  of  management 
of  technological  change  and  the  importance 
of  information  processing  to  the  entire 
University  suggest  the  continued  need  for 
skilled  planning,  analysis  and  support. 

Communications  Systems 

Although  much  of  the  computing  hardware 
would  be  dispersed  throughout  the  univer¬ 
sity,  the  network  services  should  be  provid¬ 
ed  and  controlled  centrally.  This  arises  from 
the  need  for  support  for  the  operation  of  in¬ 
terconnection  capabilities  and  the  need  to 
define  standards  so  that  the  various  inter¬ 
connected  computers  can  make  sense  of  the 


messages  being  transmitted  and  received. 
An  analogy  may  clarify  these  points.  When 
two  people  talk  on  a  telephone,  the  first  re¬ 
quirement  is  that  the  telephone  connection 
be  established  and  operational.  The  second 
is  that  both  parties  can  converse  in  a 
language  that  they  both  understand. 

User  Services  and  Publications 

These  services  should  continue  to  be  pro¬ 
vided  and  managed  centrally.  The  quality  of 
these  services  can  be  greatly  improved 
through  use  of  high  speed  interactive  dialo¬ 
gues.  The  advisors  would  be  provided  with 
tools  to  use  this  dialogue  in  responding  to 
user  enquiries  and  problems. 

The  publications  area  would  be  able  to  use 
similar  dialogue  tools  to  provide  future  do¬ 
cumentation  modules  which  would  be  on¬ 
line.  This  approach  has  several  benefits  to 
the  user  community: 

®  it  is  more  concise 
®  it  is  available  at  the  time  it  is  needed 
®  it  is  up-to-date 
®  it  reduces  paper  requirements 
@  it  can  be  electronically  connected  to  ap¬ 
plications  and  presented  automatically  in 
many  cases. 

(For  example,  instead  of  merely  presenting 
a  cryptic  error  message,  an  online  manual 
containing  detailed  information  can  be 
opened  automatically  at  the  correct  page.) 

Systems  Management 

This  function  is  critical  to  the  success  of  a 
distributed  system  and  should  be  centrally 
provided.  This  statement  is  made  in  recog¬ 
nition  of  the  following  needs: 

-  good  system  planning  and  assurance 

-  good  system  control 

-  good  personnel 

-  avoiding  the  costs  of  incoherence 

The  first  two  needs  require  the  generation 
of  specifications  for  technical  architecture, 
programming,  equipment  acquisition, 
operation  and  interconnection  in  order  to 
ensure  orderly  acquisition  and  use  of  corn- 
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puting  and  to  avoid  the  costly  errors  of  pro¬ 
gramming  difficulty,  poor  vendor  selection, 
equipment  availability,  hidden  require¬ 
ments,  etc. 

A  central  staff  of  computing  would  provide 
the  dedication  and  skill  required  to  imple¬ 
ment  and  maintain  the  systems,  to  attract 
other  good  professionals  and  to  comple¬ 
ment  the  individuals  in  the  group  with  the 
experiences  of  their  colleagues. 

Incoherence  is  often  the  costly  consequence 
of  several  autonomous  systems  initially 
operating  as  separate  entities,  with  no  re¬ 
quirements  to  share  their  facilities  or  data 
with  others.  This  situation  becomes  very 
expensive  if  it  is  later  discovered  that  simi¬ 
lar  data  or  facilities  are  required  by  several 
systems  but  that  existing  arrangements  are 
incompatible  with  each  other.  A  central¬ 
ized  system  management  function  would 


enhance  rather  than  impede  the  usefulness 
or  autonomy  of  individual  nodes. 

To  summarize,  the  industry  trends  can  best 
be  applied  at  the  University  of  Toronto  in 
the  following  way: 

•  centralized  and  decentralized  hardware 
resources 

®  centralized  operations,  but  minimal 
operational  staff  for  decentralized  activi¬ 
ties 

®  centralized  User  Services  and  Publica¬ 
tions,  expanded  in  utility  due  to  their 
ability  to  be  accessed  from  the  decentral¬ 
ized  facilities 

•  fully  centralized  system  software 
development/assurance,  communications 
systems  and  systems  management 

Terry  J.  Wood 
Ian  F.  Darwin 


COMPUTING  USES  IN  HIGHER  EDUCATION  -  SOME  OPINIONS 


Editors  Note:  The  following  opinion  is  re¬ 
printed,  in  part,  from  the  ACM  S/GUCC 
newsletter,  Volume  10,  No.  3,  Fall  1980. 

In  expressing  opinions,  the  intent  is  not  to 
make  subjective  judgments  of  what  is  good 
or  bad,  but  to  indicate  what  is  happening. 
The  educational  and  management  goals  and 
objectives  of  each  institution  dictate  the  de¬ 
gree  to  which  computer  technology  may  be 
incorporated  into  the  academic  and  admin¬ 
istrative  programs.  Dr.  Van  Horn,  Vice 
President  of  Carnegie-Mellon,  has  classified 
the  strategies  for  the  role  of  computing  in 
universities  into  four  convenient  categories. 

The  first  category,  “high  technology,”  de- 
lines  computing  as  so  basic  to  the  educa¬ 
tional  process  as  to  involve  every  student  in 
the  use  of  computing  for  the  full  four  year 
education. 

The  second  category  defines  computing  as 
“basic  core  usage”  which  sees  computing 
as  a  universal  tool  with  frequent  student  in¬ 


volvement. 

The  third  category  defines  “computer 
literacy”  as  a  goal  for  every  student  with 
limited  other  uses. 

The  fourth  category  defines  computing  as 
“an  interesting  subject”  with  interested 
students  becoming  acquainted  with  comput¬ 
ing  while  at  the  institution. 

Dr.  Van  Horn  makes  the  point  that  any 
comparison  between  universities  is  ap¬ 
propriate  only  between  universities  with 
similar  strategies. 

The  present  state  of  the  art  indicates  that 
sixty  per  cent  of  the  universities  in  a  survey 
(by  James  L.  Moss)  of  university  computer 
centre  directors  conducted  in  Spring  1980 
already  are  doing  half  of  the  institutional 
and  research  computing  in  an  interactive 
mode.  By  1985,  more  than  90  per  cent  ex¬ 
pect  to  be  doing  at  least  half  in  an  interac¬ 
tive  computing  mode.  All  respondents  ex- 


continued... 


Page  14 


UTCS 


COMPUTING  USES  continued 

pected  to  be  doing  at  least  50  per  cent  in¬ 
teractive  computing  by  1990.  The  estimate 
for  the  end  of  the  century  is  that  75  per 
cent  of  all  computing  will  be  interactive. 
Clearly  the  transition  from  batch  to  interac¬ 
tive  computing  which  started  in  the  past  de¬ 
cade  will  accelerate  in  the  future.  Howev¬ 
er,  batch  processing  is  expected  to  still  be 
around  in  the  year  2000. 

Computer  literacy  for  university  faculty,  ad¬ 
ministrators  and  students  as  well  as  for  high 
school  students  and  the  general  public  is 
expected  to  increase  dramatically  over  the 
next  20  years,  with  the  level  of  literacy  of 
high  school  students  expected  to  be  higher 
than  that  of  university  faculty  and  adminis¬ 
trators  by  1990.  (Perhaps  we  should  all 
push  our  on-campus  training  programs.) 
The  growth  of  micros  and  personal  comput¬ 
ers  is  predicted  to  be  the  most  dramatic 
change  in  the  next  decade  with  a  few 
universities  expecting  all  students  to  have 
their  own  personal  computers,  networked 
to  other  campus  systems,  as  early  as  1990. 
Twenty-six  per  cent  expect  this  to  be  true 
by  the  end  of  this  century. 

Similarly,  the  next  two  decades  can  be  ex¬ 
pected  to  show  dramatic  growth  in  the  use 
of  interactive  graphics.  Almost  all  (i.e.,  91 
per  cent)  of  the  respondents  expect  at  least 
half  of  their  applicable  students  to  be  using 
interactive  graphics  prior  to  2000. 

In  the  shorter  term,  it  is  clear  that  there 
will  be  a  great  deal  of  expansion  in  word 
processing  and  in  the  development  of  on¬ 
line  administrative  systems.  Simultaneous¬ 
ly,  you  can  expect  to  see  significant 
numbers  of  senior  administrative  officers 
start  to  use  terminals  personally  to  obtain 
online  management  information. 

Some  things  that  most  university  computer 
center  directors  do  not  expect  to  see  during 


the  next  twenty  years,  or  perhaps  ever,  in¬ 
clude:  the  elimination  of  the  central  com¬ 
puter  center  staff,  total  removal  of  large- 
scale  systems  in  favor  of  minis  and  micros 
or  the  transfer  of  large  amounts  of  academ¬ 
ic  administrative  or  research  computing  to 
off-campus  installations  via  networking  -- 
although  all  expect  that  some  small  but 
growing  amounts  will  be  shifted  off- 
campus. 

Computing  is  expected  to  demand  increas¬ 
ingly  greater  amounts  of  student  time. 
While  63  per  cent  reported  students  are 
spending  about  1  hour  per  week  involved  in 
computing  now,  half  of  the  respondents  ex¬ 
pect  the  average  student  to  be  spending 
four  hours  a  day  doing  computer-related 
work  by  the  end  of  the  century. 

The  more  dramatic  technological  changes, 
such  as  electronic  books,  paperless  offices, 
plain  language  programming  and  the  elimi¬ 
nation  of  tape  drives  and  rotating  disk 
storage,  are  expected  to  start  to  appear  later 
in  this  decade  but  are  not  expected  to  be¬ 
come  common  for  several  years  after  that. 

In  summary,  you  can  expect  dramatic  new 
developments  in  the  use  of  computer  tech¬ 
nology  as  the  transition  continues  from  the 
accounting  and  numerical  functions  of  the 
sixties  and  the  general  purpose  and  interac¬ 
tive  uses  in  the  seventies  to  the  all  per¬ 
vasive  computerization  of  society  which  will 
impact  most  academic  and  administrative 
areas  in  the  academic  communities  of  the 
future.  These  demands  for  creative  imple¬ 
mentation  of  new  technological  develop¬ 
ments  should  continue  to  provide  a  chal¬ 
lenge  to  computer  professionals  for  many 
years. 

James  L.  Moss 

James  L.  Moss  is  the  Director  oj'  Computer 
Services  at  Rensselaer  Polytechnic  Institute. 
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MATH  PACKAGES  ON  THE  DEC-10 


UTCS  currently  has  a  number  of 
mathematical  routines  and  packages  avail¬ 
able  on  the  DEC- 10  computer.  Brief 
descriptions  of  these  items  can  be  obtained 
by  typing  HELP  MATHPK.  For  the  most 
part,  these  routines  and  packages  have  been 
taken  from  the  DECUS  Library,  a  collec¬ 
tion  of  programs  submitted  by  various  users 
of  DEC- 10  systems. 

UTCS  would  be  interested  in  receiving 


comments  from  users  regarding  the  pro¬ 
grams  currently  available.  Additionally  we 
would  like  to  know  if  users  have  programs 
they  would  like  made  publicly  available. 
Suggestions  as  to  programs  that  would  be 
useful  are  also  invited.  Comments  on  these 
points  can  be  sent  to  Bob  Chambers, 
UTCS,  Room  350,  McLennan  Labs. 


Bob  Chambers 


DATA  ENTRY  AND  KEYPUNCHING  SERVICE 


The  Data  Entry  and  Keypunching  Depart¬ 
ment  is  located  at  215  Huron  Street,  Room 
406.  Our  service  is  used  by  many  depart¬ 
ments  and  faculties  including  Personnel, 
Payroll,  Accounting,  Faculty  Club,  UTCS 
users  and  non-profit  organizations.  The 
types  of  documents  we  process  include  in¬ 
voices,  purchase  orders,  journal  entries, 
payroll,  personnel,  questionnaires  and  la¬ 
bels. 

Data  are  entered  on  Sperry-Univac  CADE 
1900  equipment.  CADE  is  a  key-to-disk 
computer  system  and  has  disk  capacity  of 
8.8  million  bytes  with  maximum  memory 
of  128k.  Programs  (formats)  for  data  entry 
and  keypunching  are  written  in  COBOL. 
CADE  1900  has  features  such  as  editing, 
table  look-ups,  subroutines  and  arithmetic 
computations. 

The  output  medium  can  be  a  disk  file,  tape 
file,  cards  or  print.  Data  can  be  transmitted 
to  data  sets  on  the  IBM  3033A  (Academic) 
computer.  Disk  data  sets  are  allocated  by 
the  user  or  the  data  entry  supervisor.  A 
tape  file  is  written  at  1600  BPI  and  may  be 
labeled  or  unlabeled,  blocked  or  unblocked. 
Records  for  a  tape  file  can  be  from  14  to 
999  characters  in  length  and  for  a  disk  file 
must  be  at  least  80  characters. 

Physical  plant  utilizes  the  distributed  data 


entry  facility  of  CADE.  Two  CADE  termi¬ 
nals  are  located  in  that  department.  Docu¬ 
ments  such  as  payroll  worksheets,  purchase 
orders  and  job  orders  are  entered  on  these 
terminals. 

The  data  entry  operators  are  experienced, 
fast  and  accurate,  maintaining  an  error  rate 
of  less  than  2%  per  1000  keystrokes  for  un¬ 
verified  work  and  less  than  0.03%  per  1000 
verified  keystrokes.  Charges  for  data  entry 
or  keypunching  service  are  as  follows: 


2  weeks  turnaround 

S  1.60  per  1000  keystrokes  keypunched 

1.60  per  1000  keystrokes  verified 


3  days  or  less  turnaround 

S  2.50  per  1000  keystrokes  keypunched 

2.50  per  1000  keystrokes  verified 

Handling  charge  (if  any) 

Si 5.00  per  hour 


Programming 

$30.00  per  hour 

For  more  information  about  data  entry  and 
keypunching  please  contact  Mrs.  Betty 
Chan  or  Miss  Euphena  (Zelda)  Anderson  at 
978-5273  between  9:00  am  and  3:30  pm. 

Euphena  Anderson 
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TEXT  ENTRY  SERVICES 


The  Text  Entry  Department  is  located  in 
McLennan  Physical  Labs,  60  St.  George 
Street,  Room  331  A.  This  department  has 
been  established  to  assist  the  University 
community  with  text  processing  require¬ 
ments. 

This  could  cover  a  varied  range  of  material 
from  secretarial  correspondence  -  e.g., 
letters,  reports  -  to  large  scale  documents 
such  as  theses,  journals  and  books. 

To  expand,  consider  a  letter  or  a  report 
with  the  same  contents  being  mailed  out  to 
several  recipients.  This  can  be  achieved  by 
merging  each  address  with  the  letter/report, 
producing  clear  crisp  copies,  each  appearing 
as  an  original,  allowing  more  time  for  other 
important  and  necessary  duties. 


Lor  larger  texts,  such  as  a  thesis,  the  origi¬ 
nal  material  can  be  entered  and  formatted 
as  requested.  A  rough  draft  is  produced  for 
proofreading  and  any  insertions,  corrections 
or  revisions  can  be  made  with  minimum 
time  and  effort.  This  process  may  be  re¬ 
peated  until  ultimately  the  final  copy  is 
completed. 

Typewritten,  ‘readable,’  handwritten  and 
tape-recorded  material  can  be  submitted  at 
a  cost  of  Si 5.00  per  hour  including  storage 
and  (draft)  output.  Lor  further  information 
please  contact  Mrs.  Dale  Wright  at  978- 
4565  between  9:00  am  and  3:30  pm. 


Dale  Wright 


PERSONNEL  CHANGES 


There  are  two  additions  to  our  staff  this 
month.  We  extend  a  welcome  to  Mr.  Allen 
Ng,  who  will  be  joining  the  Administrative 
Computing  Group  and  William  Barek  who 
is  the  new  programmer  in  Academic  Com¬ 
puting  Services. 


Greg  Girard  has  left  CSS  and  Mike  Wilde 
has  left  Systems  Group  to  work  in  the  U.S. 
We  wish  them  luck. 


Theresa  Veira 


USER  EXCHANGE  COLUMN 


PL/l  Interest  Group 

To  All  Large  Users  of  PL/l : 

I  suggest  that  we  form  some  kind  of  organi¬ 
zation.  It  could  be  quite  informal  and  not 
ever  even  meet,  but  just  communicate  by 
circulars  and  phone  calls. 

There  are  common  interests,  e.g.. 


The  University  does  not  own  any 
mainframe  computers.  The  very  idea 
of  owning  or  leasing  a  mainframe 
computer  is  under  strong  attack  at 
present.  However,  as  of  March,  1981, 
no  minicomputer  has  a  compiler  for  a 
decently  full  version  of  PL/I.  Hence 
we  have  to  urge  the  University  Ad¬ 
ministration  to  retain  a  mainframe 
computer. 


continued... 
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USER  EXCHANGE  COLUMN  continued 
2.  There  is  no  end  to  the  things  that  can 
be  learned  about  combining  the 
Checkout  and  Optimizing  Compilers. 
Sharing  of  experience  would  be  of  ad¬ 
vantage  here.  The  manuals  don’t  tell 
all. 

If  you  are  interested,  kindly  call  me  at 
964-0609  or  978-3606. 


Prof.  M.  Bersohn  (Chemistry) 


Optical  Scanner  and  Card  Sorter  for  Sale 

The  following  two  items  are  being  offered 
for  sale  (best  price  offered)  by  the  Medical 


Computing  Department  of  the  Faculty  of 

Medicine. 

1.  One  OPSCAN-100  optical  card  reader 
and  card  punch.  Transfers 
numeric/alphabetic  information  coded 
on  either  standard  forms  or  user 
designed  8  1/2  x  11  forms  to  standard 
80  column  punch  cards  in  a  user 
specified  format. 

2.  One  IBM  083  card  sorter  equipped 
with  counters  for  each  card  stacker,  as 
well  as  an  overall  card  counter. 

For  both  items  contact: 

Steven  Hoke 
Faculty  of  Medicine 
978-8761 


NEW  TITLES  IN  THE  DCS  LIBRARY 


CERN  School  of  Computing,  Godoysund, 
Norway,  Aug.  1974. 

Proceedings. 

Geneva,  European  Organization  for 
Nuclear  Research,  1974. 

Communications  and  Information  Institute. 
Trends  and  recent  developments  in 
telecommunications  policy  and 
regulation  in  the  United  States. 

Brookline,  Mass.,  Information  Gatekeepers,  1980. 

Compcon,  20th,  San  Francis,  1980. 

VLSI:  new  architectural  horizons. 

New  York,  IEEE,  1980. 

Computer  Personnel  Research  Conference. 
Proceedings,  17th  (1980). 

Constable,  R.L.  and  O’Donnell,  M.J. 

A  programming  logic,  with  an  introduction 
to  the  PL/CV  verifier. 

Cambridge,  Mass.,  Winthrop,  1978. 

Cooley,  Mike. 

Architect  or  bee? 

The  human/technology  relationship. 


Slough,  England,  Langley  Technical 
Services,  1980. 

DeMillo,  Richard  A.,  ed. 

Foundations  of  secure  computation,  ed. 
New  York,  Academic  Press,  1978. 

Fairweather,  Graeme. 

Finite  element  Galerkin  methods 
for  differential  equations. 

New  York,  Marcel  Dekker,  Inc.,  1978. 

Gore,  Marvin. 

Elements  of  systems  analysis  for 
business  data  processing.  2d  ed. 
Dubuque,  Iowa,  Wm.  C.  Brown,  1979. 

Gore,  Marvin. 

Elements  of  systems  analysis  for 
business  data  processing.  2d  ed. 

Student  workbook. 

Dubuque,  Iowa,  Wm.  C.  Brown,  1979. 

I  FI  P  Conference  on  Human  Choice  and 
Computers,  2,  ed.  by  A.  Mowshowitz. 
Amsterdam,  North-Holland,  1980. 

International  Conference  on  Very 
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NEW  TITLES  continued 

Large  Data  Bases,  6th,  Montreal, 

Oct.  1980. 

Proceedings. 

New  York,  IEEE,  1980. 

I  FI  P  Workshop  on  Methodology  of 
Interaction,  Sei  I  lac,  France,  1979. 
Methodology  of  interaction,  ed. 
by  R.A.  Guedj  et  al. 

Amsterdam,  North-Holland,  1980. 

International  Research  Conference  on 
the  History  of  Computing,  Los  Alamos 
Scientific  Laboratory,  1976. 

A  history  of  computing  in  the 
twentieth  century;  a  collection  of 
essays,  ed.  by  N.  Metropolis  et  al. 

New  York,  Academic  Press,  1980. 

JIPDEC  Information  Systems  Seminar  on 
Semantic  Aspects  of  Databases,  Tokyo, 
Eeb.  1980. 

Proceedings. 

Tokyo,  Japan  Information  Processing 
Development  Center,  1980. 

Lucas,  Henry  C.,  Jr. 

The  analysis,  design,  and  implementation 
of  information  systems.  2d  ed. 


New  York,  McGraw-Hill,  1981. 

Sauer,  C.H.  and  C’handy,  K.M. 

Computer  systems  performance  modeling. 
Englewood  Cliffs,  N.J.,  Prentice-Hall,  1981. 

Watson,  G.  Alistair. 

Approximation  theory  and  numerical  methods. 
Chichester,  Eng.,  Wiley,  1980. 

Wegner,  Peter. 

Programming  with  Ada:  an  introduction 
by  means  of  graduated  examples. 

Englewood  Cliffs,  N.J.,  Prentice-Hall,  1980. 

Workshop  on  Computers  and  Privacy  in 
the  Next  Decade,  Pacific  Grove,  Cal.,  1979. 
Computers  and  privacy  in  the  next 
decade,  ed.  by  Lance  J.  Hoffman. 

New  York,  Academic  Press,  1980. 

Wulf,  William  A.  et  al. 

Fundamental  structures  of  computer  science. 
Reading,  Mass.,  Addison-Wesley,  1981. 

Yourdon  E.  and  Constantine,  L.L. 

Structured  design:  fundamentals 
of  a  discipline  of  computer  program 
and  systems  design. 

Englewood  Cliffs,  N.J.,  Prentice-Hall,  1979. 
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UTCS  SYSTEMS 


3033/N8A  PROCESSOR 


•  located  in  McLennan  Physical  Laboratories 

•  provides  General  Purpose  Job  Stream,  High 
Speed  Job  Stream,  TSO,  WYLBUR 

•  8  megabytes  of  memory 

•  MVS  with  JES2 

3033/N8B  PROCESSOR 


•  located  in  McLennan  Physical  Laboratories 
©  provides  administrative  IMS/VS 

DB/DC  Batch,  TSO,  MVS/APL 
and  ATMS  services 

•  8  megabytes  of  memory 

•  MVS  with  JES2 

DECSY STEM-10  Model  1090 


©  located  in  McLennan  Physical  Laboratories 
©  provides  General  Purpose  Time-Sharing 

•  256  K  -  36  bit  words  of  memory 

•  TOPS-10  operating  system 


COMMUNICATIONS  &  SMALL 
SYSTEMS  (CSS) 


•  located  in  SF308 

•  DEC  GT44  System  with  PDP-1 1/40  CPU 

•  2  Z80  based  microcomputers 

•  Radio  Shack  TRS-80 

•  Western  Digital  Pascal  MicroEngine 

©  Apple  II  Plus 

•  DEC  GT40  System  with  PDP-1 1/05  CPU 

•  provides  specialized  graphics  and  inter¬ 
active  graphics 

•  provides  online  and  real-time  computing 
services,  data  acquisition  and  minicomputer 
services 


UTCS 


UTCS  DIRECTORY 


POSITION 


CENTREX 

ROOM  PHONE  NUMBER 


Director 

Dr.  Doron  Cohen  MP350  8948 

Associate  Directors 

Rein  Mikkor  MP350  5058 

A1  Heyworth  MP350  4936 

Faculty  Liaison  Officer 
&  Manager,  Text  Services 

Dr.  Frank  Spitzer  MP350  4619 

Manager,  Communications 
&  Small  Systems 

Eugene  Siciunas  MP350  4967 

Manager,  Operations 

Derry  Cox  MP350  7092 

Manager,  Systems 

Ward  Beattie  MP350  3579 

Manager,  Academic  Computing 
Services 

Ralph  Lombardi  MP350  7130 

Manager,  Administrative 
Computing  Services 

Bill  Lauriston  (Acting  Manager)  SG201  6877 

Manager,  Services  Support 

Don  Gibson  MP350  5568 

Administrative  Officer 

Suzan  Fawcett  MP350  4428 

Information  &  Accounting  Office 

General  Inquiries  EA206  4990 

Accounts 

Aggie  Stevens  (U  of  T)  EA206  8702 

Sylvia  May  (External)  EA206  7148 

Supervisor,  Accounting 
&  Information  Services 

Marg  Doherty  EA206  3960 

Access  Codes 

Michelle  Mule  EA206  8703 

Supervisor,  Communication  Systems 

Walter  Rosocha  SF302  7087 

Programming  Services 

Bill  Lauriston 


SG201 


6877 
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UTCS  DIRECTORY  continued 


Entry  Services 


Supervisor 


Vera  Cabanus 

MP331 

5040 

Text  Entry 

Dale  Wright 

MP331 

4565 

Data  Entry 

Zelda  Anderson 

MP331 

5273 

Keypunching 

Dale  Wright 

MP331 

4565 

Tape  Librarians 

Academic  Services 

MP368 

7319 

Administrative  Services 

MP368A 

6693 

Supervisor,  Applications 

Herb  Kugel 

SG304 

7286 

Computing  Services  Representatives 

Engineering  Annex  Terminal 

Sue  Chong 

EA  104 

4357 

Program  Advisors 

EA103 

4516 

Time-Sharing  Support 

TS  Advisors 

SG204 

6465 

John  Mavity 

SG204 

7109 

Erindale 

Peter  Wall 

2043 

828-5311 

Scarborough 

Bob  Blackburn 

284-3173 

Arts  and  Science 

Bill  Fehlner 

SS2133 

6509 

New  Physics 

Bob  Chambers 

MP1202 

8823 

External 

Ihor  Prociuk 

SG205 

6875,6885 

Supervisors,  Operations 

Paul  Scarborough  (IBM  3683N8A) 

MP335 

6220 

Krishna  Patnaik  (DEC-1090  &  CSS) 

MP368 

4086 

Dave  Wong  (IBM  3033N8B) 

MP368 

6864 

Key: 

EA  =  Engineering  Annex  SF  =  Sandford  Fleming 

SG  =  49  St.  George  SS  =  Sidney  Smith 

HU  =  215  Huron  St. 

MP  =  McLennan  Physical  Laboratories  (New  Physics) 

Job  and  System  Status  Queries 

SYSTEM/3033, TSO 
ATMS/APL 


Time-Sharing 

Services 

APL,ATMS 
TSO,WYLBUR 
DEC- 10  Services 


Dial-Up 

7200  Centrex 

7201  Non  Centrex 

6200  Centrex 

6201  Non  Centrex 
4224  Centrex 
4244  Non  Centrex 
6465 


7373 

6234 
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